CÓMO MONTAR UNA 
SERVIDORA FEMINISTA 








PARTE III 


De máquina 
a servidora web 





ekka 


la bekka <espacio hackfeminista> 
https://labekka.red 
hacklabfeminista@riseup.net 

GPG 0xD47C2A1A064B0D97 


Proceso de aprendizaje: 
rene, m4rtu, Inés Binder, Andrea, Marta S. 


Redacción y contenidos: 
nés Binder y m4rtu. 


Diseño y diagramación: 
nés Binder y m4rtu. 








mpreso en Canarias. 


OO 


O la_bekka, septiembre 2019 


Este fanzine se libera bajo la licencia Producción Feminista de Pares. Esto significa 
que, reconociendo la autoría de la obra, se permite compartirla (copiarla, distribuirla, 
o comunicarla públicamente) y hacer obras derivadas y explotarlas comercialmente 
solamente si eres parte de una cooperativa, organización o colectiva sin fines de 
lucro, u organización de trabajadoras autogestionadas, que defiendan y se organicen 
bajo principios feministas. Además, debes compartir cualquier obra derivada de este 
fanzine con la misma licencia. 


PARTE Il; 
DE MAQUINA A 
SERVIDORA 


Contenidos 


9. Instalemos una servidora web en la Raspberry Pi 


10. Hagamos la servidora accesible desde Internet 





11. Configuremos Let's Encrypt 


9. Instalemos una servidora web en la Raspberry Pi 


Existen diferentes programas para dar vida a una servidora web. 
Los más conocidos son Apache y nGinx. Pueden averiguar las ca- 
racterísticas de cada uno y evaluar cuál les conviene. En este caso 
nosotras elegimos Apache y seguiremos los pasos para instalarlo. 
Básicamente consiste en ejecutar en la terminal de la Raspberry Pi 
(puede ser ya de manera remota desde nuestra computadora/orde- 
nador o desde la propia Raspberry Pi) el comando para instalar pa- 


quetes en Raspbian: 


sudo apt-get install apache2 


¡Síl, así de fácil. Para comprobar que se ha instalado correcta- 
mente y que está activo podemos ir al navegador de nuestra com- 
putadora/ordenador y escribir la dirección IP de la Raspberry Pi 
(recuerden que todavía debemos estar conectadas a la misma red). 
Si no ha cambiado nada será la dirección IP que usaron para conec- 
tarse por SSH. Y si se la han olvidado recuerden ejecutar el comando 


hostname -I en la consola de la Raspberry Pi. 


Debería aparecerles la página de Apache por defecto gue indica 
gue su servidor web está corriendo correctamente en la Raspberry 
Pi. Emocionante, éno? Esa página que nos muestra se llama in- 
dex.html y está guardada en el directorio "root de Apache" 
/var/www/html/ de nuestra Raspberry Pi. Si quieren cambiarla y 
hacer su propia página web de prueba pueden cambiarle el nombre 


a ese archivo para respaldarlo: 


sudo mv /var/ww/html/index.html 


/var/ww/html/index.html.old 


Y luego crear un nuevo archivo index.html con lo que ustedes 


quieran: 
sudo nano /var/ww/html/index.html 


Para ponerle contenido tienen que saber un poquito de la sin- 
taxis de HTML. Pueden empezar con este ejemplo sencillo: 

<html> 

iHola amigas! 


</html> 


Guardamos, salimos y refrescamos la página en el navegador 
para ver si se reflejan los cambios. jY voilá! Si no ven los cambios 
prueben volver a cargarla con Ctrl + F5. Si incluso así no se re- 
flejan los cambios prueben abrir la página con una pestaña en modo 
incógnito o borrar la caché. En ocasiones se queda guardada en 


caché la versión antigua de la web. 


De todos modos esta web sólo se puede ver desde las computa- 
doras que están conectadas al router al que está conectado la servi- 


dora. Todavía no es accesible desde Internet. 


En este punto pueden probar trastear/cacharrear/jugar/experi- 
mentar con HTML. Pueden poner, por ejemplo, una imagen: <img 
src="http://urldela.imagen.com/foto.jpg">. Hay muu- 
uuuuuuuuucha documentación en Internet sobre HTML, plantillas, 


trucos, secretos, etc. 


Más adelante veremos algunos archivos de configuración de 
Apache como /etc/apache2/conf -enabled/security.conf, 
/etc/apache2/apache2.conf o .htaccess. Recuerden que 
cada vez que modifiquemos cualquier parámetro en un archivo de 
configuración tenemos que reiniciar el servicio para que los cam- 


bios se hagan efectivos. En el caso de Apache debemos escribir: 
sudo service apache2 restart 
También se puede reiniciar haciendo: 


sudo systemclt restart apache2 


10. Hagamos la servidora accesible desde Internet 


¡Atención! Antes de seguir los pasos de este apartado 
es necesario securizar la servidora ya que en el mo- 
mento en el que sea accesible desde Internet va a em- 
pezar a recibir intentos de conexión. No serán 
necesariamente personas que estén buscando meterse 
en nuestra servidora sino intentos automáticos de bots 
que quieren aprovecharse de infraestructura ajena. Les 
recomendamos Saltar a la parte IV y securizar la 


servidora antes de continuar. 


Una vez que tengan su pequeña servidora corriendo y securizada 
vamos a ver cómo lograr que cualquier persona en Internet pueda 
ver la página web alojada en nuestra servidora casera, "detrás" de 
un router casero. Es importante que repasen toda la parte IV antes 
de empezar con esta ya que cuando salgan a Internet estarán vul- 


nerables a posibles ataques. 


Lo que vamos a aprender ahora es cómo configurar el router para 
que las conexiones externas (que vienen desde Internet) se en- 
caminen (se redirijan) a la servidora y nunca a otro dispositivo de la 


red. También veremos cómo asociar un dominio a la servidora. 


Lo que viene ahora quizás les parezca más complejo con con- 
ceptos nuevos sobre redes y protocolos. Pónganse cómodas porque 


cuando funcione ¡será un subidón! 
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10.1 El router de casa o la comunidad 


Comencemos accediendo al panel de control del router. ¿Se 
acuerdan cómo? Tienen que abrir un navegador y escribir en la barra 
de direcciones la dirección IP local del router (192.168.1.1 O 
192.168.0.1). Entren con la usuaria y contraseña que le hayan con- 


figurado en la parte IV. 


Una vez que ya estén dentro del panel de control de su router 
pueden echar un vistazo a los diferentes menús y opciones 
disponibles, ahora con más detalle. Como ya saben todos estos 
menús varían según el fabricante así que aquí no vamos a poder 
guiarlas paso a paso. Las animamos a guiarse por su intuición, un 
poco de inglés y algunos manuales en Internet. De todos modos los 


routers caseros son más o menos similares. 


Algo importante de saber de los routers caseros es que -a dife- 
rencia de los móviles o las computadoras- en vez de tener una sola 
dirección IP con la que se los identifica en la red tienen dos direc- 
ciones IP: una privada o local y otra pública. Lo que hace el router es 
gestionar y encaminar el tráfico que hay entre la red local y la red de 
Internet. Por lo general, el router va a dejar salir todo el tráfico que 
los dispositivos de la red local estén enviando a Internet y deja en- 
trar sólo el tráfico que éstos dispositivos hayan solicitado. Orde- 
nadamente, redirige las peticiones que le llegan a cada quien que las 


haya pedido. 


Una topología de red presente en una casa o comunidad pequeña 


suele ser así: 


192.168.1.144, 


Y 





ROUTER RASPBERRY PI 


Intenten dibujar un pequeño esquema que refleje cómo es su red 


local con las direccione IP de cada dispositivo conectado. 





En la 


configuración del router suele haber un apartado donde lista las di- 


recciones IP locales de los dispositivos conectados y la IP pública del 


router. La dirección IP pública del router también se puede consultar 


desde cualquier dispositivo conectado al router. Vayan al navegador 


y busquen "¿Cuál es mi dirección IP?", entre los resultados les sal- 


drán un montón de webs que les dirán con qué IP pública están 


saliendo a Internet. Nosotras usamos https://wtfismyip.com/ 


o in- 


cluso el propio Duck Duck Go te la dice. Todos los dispositivos 


conectados a un mismo router salen con la misma dirección IP, es 


decir, con la IP pública del router. 


Si la dirección IP pública que les está mostrando el navegador y 
la que ven en el router son diferentes puede ser que su proveedor de 
Internet esté haciendo una cosa que se llama CGNAT para optimizar 
el número de direcciones IP que usa entre sus clientes. Esto nos 
pasó. Tuvimos que llamar a la compañía para que nos asignaran una 


dirección IP pública y funcionó. 


Como dijimos antes, esta guía está pensada para montar una 
servidora web con una conexión casera. Puede ser la de la casa de 
alguna de ustedes pero tengan en cuenta que esto conlleva riesgos: 
a través de la dirección IP se puede identificar nuestro proveedor de 
servicios de Internet (ISP), quien a su vez tiene los datos de la per- 
sona que contrató la conexión (nombre y apellidos, probablemente 


número de identificación, dirección postal, número de teléfono, 





etc.). Esos datos están protegidos en mayor o menor medida de 
acuerdo la compañía que hayamos contratado y al país donde resi- 


damos. 
10.2 Asignar dirección IP local fija a la servidora 


Antes de terminar con la configuración del router es importante 
asignar a nuestra servidora web una dirección IP local fija para que 
podamos "localizarla" siempre con la misma IP, ya que esta suele 
cambiar cada vez que conectamos nuestro dispositivo a la red local. 
Existen varias maneras fijar una dirección IP local a un dispositivo. 
Una sencilla es ir a algún apartado de la configuración del router y 
fijar una dirección IP según la dirección MAC del dispositivo. Ten- 
gan cuidado de no ponerle una dirección IP que ya esté usando otro 


dispositivo ya que se generaría un conflicto. 
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Hay routers caseros que lo tienen sencillo y permiten elegir di- 
rectamente el nombre del dispositivo y asignarle una dirección IP. 
En otros tendrán que encontrar la dirección MAC de la tarjeta de red 


de la Raspberry Pi. Para hacerlo puede ejecutar el comando: 

ipa 

Y localizar un conjunto de 6 valores en hexadecimal del tipo: 
b8:27:eb:20:a0:9f (esto es sólo un ejemplo, cada dirección 
MAC es única para cada placa de red). Tienen que mirar la sección 
de la interfaz cableada que se suele llamar eth0, ahí también po- 


drán ver la dirección IP. No se confundan con la MAC de la interfaz 


inalámbrica que se suele llamar wlan0. 
10.3 Configurar red DMZ 


Ahora nuestro objetivo será configurar el router para que nuestra 
servidora sea accesible desde Internet y no sólo desde el salón de 
nuestra casa o comunidad. Para ello debemos abrir algunos puertos. 
Pero, ¿cómo?, ¿es esto seguro para los demás dispositivos que estén 
conectados a esa red? Vamos a ver cómo asegurarnos de no poner- 


nos en riesgo. 


Para "abrir esas puertas" en el router hay varias opciones. Una 
opción que nos recomendaron es configurar una red DMZ (las siglas 
significan "zona desmilitarizada" en inglés) en el router. Lo que 
hace esta red es que cualquier petición externa que reciba el router y 
que considere "desconocida" la dirija a la dirección IP local que le 
asignemos. En este caso será la de nuestra servidora que ahora 


tiene dirección IP local fija. 


Con "Petición externa desconocida" nos referimos a una 
conexión que venga de Internet y que ningún dispositivo de la red 
local ha pedido. La situación es la opuesta a cuando estamos con- 
sultando un sitio web desde nuestra computadora. En ese caso 
recibimos la conexión que hemos pedido y por lo tanto para el router 


esta petición es "conocida". 


Una servidora web sí tiene que poder aceptar peticiones des- 
conocidas, que vengan desde "afuera", para poder ofrecer los con- 
tenidos web alojados en ella. Este es el sentido "pasivo" de "servir" 
una web. La servidora estará a la espera de que lleguen esas peti- 


ciones desconocidas para satisfacerlas. 


La red DMZ aísla al resto de dispositivos de la red interna de 
conexiones desconocidas y redirige el tráfico que queremos a la 


servidora. 


Quizás les ayuda este diagrama sobre peticiones web: 


Y La compu pide a la servidora web 
lí SS 
La servidora web contesta a la compu EL 
_ _ _ _ ——__—— 
RASPBERRI PI 
COMPUTADORA (SERVIDORA) 


En la primera conexión la servidora recibe una conexión "des- 
conocida", algo que ella no ha pedido. En la segunda conexión la 
computadora recibe una conexión conocida que es la respuesta a 


una petición que ella ha hecho. 


En el router que nosotras usamos la configuración de la red DMZ 
está en "Seguridad > Security" o puede estar también en "Configu- 
ración avanzada". Ahí se activa y se pone el "LAN host" (el diposi- 


tivo de la red local) al que se van a redirigir las conexiones externas 





desconocidas. Ahí tendremos que poner la dirección IP de la servi- 
dora. ¿Se acuerdan cómo averiguarla? Tenemos que escribir en la 


consola: hostname -I. 


Una alternativa a configurar una red DMZ en el router es con- 
figurar el "Port forwarding" para que la servidora sea accesible desde 
Internet y dirija las conexiones no solicitadas a una dirección IP es- 
pecífica. Tendrán que configurarlo para los puertos 80, 443 y para el 
que hayan elegido para las conexiones SSH (en nuestro caso el 2251, 
por ejemplo), por lo menos. Esto nos ha dado varios dolores de 


cabeza así que te recomendamos la red DMZ. 


Para comprobar que esta configuración funcionó pueden poner 
en su navegador la dirección IP pública asignada al router y les de- 


bería mostrar su página web. ¡Espectacular! 
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10.4 Gestionar DNS dinámicos 


Como nuestra red es casera nuestro proveedor de servicios de 


Internet no nos asigna una dirección IP pública fija para el router. Es 





decir, un día nos conectamos con una, a la semana con otra, etc. Es 
una cuestión de que no hay suficientes direcciones IP públicas para 
todos los router que hay en el mundo. Si quieres una IP pública fija 
tienes que pagar un extra al proveedor de servicios de Internet. Los 
servidores grandes que pertenecen a instituciones o empresas 


suelen pagar por este servicio. 


En este caso quienes quisieran visitar nuestra web tendrían que 
enterarse de cuál es nuestra dirección IP de la semana. Para sol- 
ventar esto necesitamos un servicio de DNS dinámico que nos per- 
mita vincular un dominio con una dirección IP dinámica pública 
como la que tenemos en una conexión casera. Lo que hace este 
servicio es estar atento a los cambios de la dirección IP pública de 


nuestro router y actualizarla en la vinculación con nuestro dominio. 


El servicio que vincula direcciones IP públicas con nombres de 





dominio se llama DNS (Domain Name System). Existen servidores 
DNS que proveen este servicio. Pero primero necesitamos un do- 


minio. 
Conseguir un dominio 


Para proceder a vincular un dominio con la dirección IP 
dinámica debemos comprar un dominio. En caso de no tener dinero 


para comprar un dominio propio podemos optar por servicios gra- 
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tuitos como https://www.noip.com, que ofrecen DNS dinámico y 
prestan subdominios del tipo http://hola-amiga.noip.com o 
http://hola.ddns.net. En la propia página de Nolp hay mucha docu- 
mentación sobre cómo utilizar el servicio. La única desventaja de la 
versión gratuita es que hay que renovarla cada mes (jpst!, pero nos 
avisan para no olvidarnos). Sin embargo, creemos que puede dar 
problemas a la hora de configurar los certificados SSL/TLS usando 


Let's Encrypt. 


Nosotras compramos un dominio de nivel superior .red. Origi- 
nalmente había unos pocos: .com, .edu, .gov, .intl, .org, .net y .mil, 
además de los dominios geofráficos de nivel superior: .ar para Ar- 
gentina, .br para Brasil, etc. Pero ahora hay muchísimos. Puedes 
ver una lista completa en la página de Wikipedia de List of Internet 
top level domains. Existen muchos lugares para comprar dominios: 
varían en precio, condiciones, prestaciones, etc. Si queremos com- 
prar un dominio de país (.gt, .es, .py, etc.) debemos acudir a las 
agencias nacionales. Para dominios genéricos podemos buscar 
cualquier otro servicio. Algunos proyectos activistas/éticos que 


ofrecen dominios son: 1984hosting.com, greenhost.net o gandi.net. 


Debemos tener en cuenta que cuando compremos cualquier do- 


minio nos pedirán datos personales de contacto: nombre, dirección 





postal, correo electrónico, etc. Esos datos (llamados informalmente 
'WHOIS') serán públicos salvo que pidamos que no los muestren. 
Algunas compañías cobran por este servicio y otras no. Es impor- 
tante hacer una evaluación de riesgos para saber qué datos dar y 


cómo protegerlos. También será necesario pensar cómo hacer el 
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pago. Algunos proyectos como  https://1984hosting.com o 
https://njal.la permiten hacer la compra con criptomonedas en vez 


de tener que usar una tarjeta de crédito. Incluso https://gwass.com/ 





acepta Faircoins, una criptomoneda ética. Esto nos puede ayudar a 


proteger nuestra privacidad. 


Para comprar el dominio tendremos que crearnos un perfil para 
acceder a un panel de control que nos permitirá gestionar una serie 
de parámetros que veremos más adelante. jUsen una buena con- 


traseña y a guardarla en su gestor de contraseñas! 


Recomendamos el uso de gestores de contraseñas 
como KeepassXC https://keepassxc.org/. Las ayudará a 
generar contraseñas fuertes, gestionarlas de manera 
ordenada, con carpetas y colores, y a guardarlas 


cifradas. 


DNS dinámicos 


Después de rebuscar servicios de DNS dinámicos nos recomen- 
daron el que provee Hurricane Electric (https://he.net). Para poder 
usar sus servicios de DNS hay que hacerse una cuenta en 
https://dns.he.net/ donde podremos configurar los registros DNS. 


Una vez que nos hayamos dado de alta vamos al panel de adminis- 
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tración de nuestro dominio en la web donde lo compramos. 
Busquen donde se puedan configurar los servidores de DNS. Allí 


tendrán que configurar como servicio de DNS a los DNS de he.net: 


ns1.he.net 
ns2.he.net 
ns3.he.net 
ns4.he.net 


ns5.he.net 


Quizás haya que esperar unos minutos hasta que la configu- 
ración se actualice. Luego volvemos al panel de control de 
dns.he.net y añadimos un nuevo registro de tipo A con los siguien- 


tes datos: 


name: nuestrodominio.net 

IPv4 Address: 1.1.1.1 

TTL: actualización del registro en segundos 
(puedes poner 300 - 5 minutos) 

Check el cuadradito "Enable entry for dynamic 


DNS" 


Una vez que añadimos el registro debemos pinchar/hacer clic en 
el símbolo de las flechitas en círculo (como de actualizar). Se nos 
abrirá una ventana de dialogo pidiendo asignar una contraseña al 
registro. Se la ponemos, confirmamos y aceptamos. ¡A guardar esa 


contraseña en el Keepass! 
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¡Ojo! Ponemos la dirección IP 1.1.1.1 que es una di- 
rección cualquiera para poder comprobar luego de ma- 
nera más sencilla que se ha cambiado a la dirección 


correcta ¡sigan leyendo! 


Configurar ddclient 


Ahora volvamos a nuestra Raspberry Pi para configurar el DNS 
dinámico. Lo haremos con un programita llamado ddclient que se 
comunicará con el servicio de DNS dinamico de he.net y le mandará 
nuestra nueva dirección IP cada vez que cambie. Para instalar el 


servicio ddclient ejecutemos: 
sudo apt-get install ddclient 
Para congifurarlo abrimos: 
sudo nano /etc/ddclient.conf 
Y escribamos la siguiente configuración estándar: 


pid=/var/run/ddclient.pid 
protocol=dyndns2 

ssl=yes 

use=web 
server=dyn.dns.he.net 
login=nuestrodominio.net 
password='contraseña' 
nuestrodominio.net 
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En el campo login tienen que poner el dominio que hayan com- 
prado y en el campo password la contraseña que hayan asignado al 
registro A. Es importante ponerla entre comillas simples. En la ul- 


tima línea tienen que poner de nuevo el dominio. 


Además hay que configurar que el ddclient funcione como dae- 
mon, es decir, como servicio que corra todo el tiempo. Para eso hay 


que editar: 
sudo nano /etc/default/ddclient 
Y cambiar las opciones para que quede así: 


run dhclient-"false" 
run_ipup="false"” 
run_daemon="true"” 


daemon_interval="300" 


Para que se hagan efectivos los cambios debemos reiniciar el 


servicio: 
sudo service ddclient restart 


Para ver si la actualización de la dirección se hizo o qué errores 


pudieron darse pueden ejecutar: 
sudo ddclient -daemon=0 -debug -noquiet 
Y también se pueden revisar los logs: 


cat /var/log/syslog* | grep ddclient 
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Si configuraron todo correctamente deberían ver los cambios en 
la página de dns.he.net. Si actualizamos la web, en el registro A (A 
Record) donde antes decía 1.1.1.1 ahora debería aparecer la dirección 
IP pública de la conexión casera donde tenemos conectada nuestra 
servidora. Para comprobar que su dirección IP está asociada a su 


dominio pueden hacer desde cualquier terminal: 
ping nuestrodominio.net 


Tengan en cuenta que quizás tarde un ratito en actualizarse la IP 
ya que tiene un TTL de 300 segundos (5 minutos). Así que esperen 


ese tiempo al menos antes de entrar en pánico. 


Recuerden que a partir de ahora para conectarse a la servidora 
por SSH pueden ejecutar el siguiente comando desde cualquier 


computadora conectada a Internet: 


sudo ssh -p 2251 pifhnuestrodominio.net 


A nosotras nos sirvió consultar esta documentación: 
- https: //www.bidon.ca/en/random/2011-06-16-using- 
dynamic-dns-feature-dnshenet 
- https://joatbloginterim.wordpress.com/2013/06/18/ 


setting-up-ddclient-on-the-raspberry-pi/ 
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11. Configuremos Let's Encrypt 


Para que el tráfico de nuestra web vaya cifrado a través del pro- 
tocolo HTTPS necesitamos configurar un certificado SSL/TLS. Estos 
certificados pueden ser de pago y algo complejos de configurar en 
Apache. Sin embargo, con la herramienta Certbot (https://cert- 
bot.eff.org/), desarrollada por la organización EFF, podemos con- 
figurar un certificado de Let's Encrypt (https://letsencrypt.org/) 


fácilmente y de forma gratuita. 


Antes de proceder necesitan haber realizado el paso anterior: 
conseguir un dominio y tener los DNS dinámicos bien configurados. 
En https://certbot.eff.org/lets-encrypt/debianstretch-apache hay 
una guía sobre cómo configurarlo (aunque está un poco desactua- 
lizada, la verdad). De hecho, dice que hace falta configurar los 
backports para poder descargar Certbot pero hemos comprobado que 


no es necesario. Así que no lo hagan. 


Para instalar Certbot hay que ejecutar el comando: 


sudo apt-get install certbot python-certbot- 


apache 


Una vez gue tengamos instalado Certbot sólo debemos seguir los 
pasos de la configuración gue nos solicita. Tendrán gue indicar el 
dominio de su servidora y un correo electrónico. Comencemos la 


instalación corriendo el asistente: 


sudo certbot --apache 


El asistente de configuración también nos preguntará si quere- 
mos redirigir las peticiones http a https. En nuestro caso diremos 
que sí tecleando el número 2 y apretando enter. Si el dominio no 
está bien asociado a una dirección IP el asistente no terminará de 


generar los certificados. 


Los certificados de Let's Encrypt sólo duran 3 meses pero se 
renuevan de manera automática. Si quieren comprobar que las 


renovaciones funcionan pueden ejecutar: 
sudo certbot renew --dry-run 


--dry-run es un modificador muy útil para probar un co- 
mando: lo ejecuta pero sin ejecutarlo realmente y nos devuelve el 
resultado de lo que ocurriría si lo ejecutáramos. Chilero, éno? Ojalá 


hubiera algo así para la vida humana. 


Ahora pueden ir al navegador, teclear su dominio y comprobar 
que tienen su certificado configurado. Verán un candadito verde en 
la barra de navegación y que la conexión se hace por el protocolo 
HTTPS. También pueden comprobar que la redirección de HTTP a 
HTTPS funciona borrando la s y corroborando que se añade au- 


tomáticamente. 


Si tienen una Raspberry Pi viejita quizás tengan algunos proble- 
mas. A nosotras nos pasó con una Raspberry Pi 1 Model B+ porque el 
Certbot que está en los repositorios de Debian Stretch (la versión de 
Debian 9 sobre la cuál está "hecha" Raspbian Stretch) no es com- 


patible con su arquitectura. Acá encontramos algunas orientaciones 


19 


para estos casos: https://community.letsencrypt.org/t/certbot-on- 
raspbian-illegal-instruction/15813. Pero no logramos configurarlo. 


Tuvimos que usar una Raspberry Pi más nueva. 


Otra opción también es usar el certbot-auto que se propone 
para cualquier sistema operativo cuando no hay desarrollado uno 
específico: https://certbot.eff.org/lets-encrypt/pip-apache. Con 


este último paso ya tenemos configurados los certificados SSL/TLS. 


¡Felicitaciones! Esta parte de la guía ha tenido muchos pasos 
pero de extrema relevancia para poder habitar Internet sin ex- 
ponernos. Y aunque ahora estamos más protegidas no tenemos que 
confiarnos. Esta es una tarea cotidiana de revisión, actualización y 
testeo permanente. Al fin y al cabo, aunque sea una máquina, a la 
servidorcita también hay que cuidarla. Les recordamos la impor- 
tancia de documentar su proceso: anotar qué hicieron, cómo, con 
qué dificultades se encontraron y cómo las resolvieron. Una suerte 
de diario que registre todas las decisiones que hemos tomado a lo 
largo del proceso. Así podremos reconstruirlo, multiplicarlo y 


volver a él cada vez que necesitemos. 
¿Les parece si desarrollamos nuestra página web? 


¡Vamos a la parte V! <3 
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